Contemporary computer systems employ various user interface (UI) mechanisms to facilitate data entry. One commonly utilised UI mechanism is the wizard. Wizards are typically employed when a data entry task lends itself to being broken down into a series of steps in order to improve the comprehensibility of the data entry task (e.g. when data to be entered by a user is deemed too confusing for entry by way of a single screen).
A wizard is a series of dialog boxes or “pages” that is presented in a particular sequence. Each page of the wizard corresponds to a step in the overall data entry task. The pages are often graphical but are not necessarily so. Typically, each page contains data entry fields of various types (e.g. radio buttons, text entry fields, checkboxes, etc.) and textual instructions describing the actions that should be taken by the user to enter data on the current page. A set of navigational controls is displayed in conjunction with each page to permit the user to traverse the wizard page-by-page. These navigational controls typically comprise four buttons: a “next” button for advancing to the next page of the wizard, a “back” button for going back to a previous page, a “finish” button and a “cancel” button (to be described).
In standard operation, upon the occurrence of a triggering event the wizard will be invoked and the first page of the wizard will be displayed. The user interacts with the wizard, by way of a mouse and keyboard for example, to enter any data requested on the first page and, when finished, selects the “next” button to advance to the second page. This process is repeated until all of the wizard's pages have been traversed. If necessary, the user may select the “back” button to review previously entered data or to correct a previous entry.
When all of the wizard's pages have been traversed and all of the required data entered, the “finish” button will become active. Upon its selection by the user, the wizard is exited and the data entered by the user is processed in accordance with the wizard's underlying “business objective” (i.e. its purpose).
Alternatively, at any stage the user may select the “cancel” button. Selection of this button causes the wizard to be terminated and any data entered in any of the wizard's pages to be lost. Disadvantageously, subsequent re-invocation of the wizard requires any data that was previously entered on any of the wizard's pages to be re-entered. As a result of this cancellation behaviour, known wizard UIs are ill-suited for phased data entry (i.e. for data entry in multiple sessions with the wizard being exited between sessions), because they are incapable of being cancelled and later resumed with previously entered data intact.
When a wizard UI is developed in an object oriented programming language such as C++ or Java™, the developer will typically utilise a standard object oriented UI class library, such as the Microsoft® Foundation Class library, the Java™ Foundation Class Swing components from SUN® Microsystems (typically referred to simply as “Swing”), or the Standard Widget Toolkit from IBM®, to facilitate wizard development. In particular, the developer will utilise various wizard-related classes from the selected class library to implement the wizard UI. These classes are usually subclassed (i.e. have classes derived therefrom) and the subclasses adapted to implement the desired wizard content according to the requirements of the application.
Wizard-related classes in standard UI class libraries normally follow a “framework-page paradigm” which defines the classes for implementing a wizard UI, as well as the interrelationships between these classes and the general functionality of each class. Two classes are central to the framework-page paradigm: the wizard framework class and the wizard page class (it is noted that these classes may have different names in class libraries).
The wizard framework class defines the baseline functionality of the wizard mechanism and generally governs wizard features that are not content-related. The wizard framework class includes fields (i.e. class variables, which are referenced herein using the lowercase word “field”, as opposed to data entry form fields, which are referenced herein using the capitalized word “Field”) and methods for displaying the wizard's navigational controls, handling navigational control events, and managing the wizard's multiple pages for example. This class is instantiated once per wizard.
The wizard page class, on the other hand, is associated with the pages that provide the wizard with its content. This class is intended to be subclassed for each of the wizard's pages, with each subclass being adapted to implement the associated page. That is, the wizard page class acts as a base class from which multiple page classes—one per wizard page—are derived; each of the derived page classes is then completed by a developer, through the addition of fields and methods for example, to effect the desired content and layout for that page. The added fields and methods are referred to as the “business logic” of the wizard, as it is here at the page level where most of the wizard's substantive processing (which effects the wizard's business objective) is performed.
At run time, page objects (i.e. adapted page class instantiations) are dynamically accessible by the wizard framework object (i.e. the instantiation of the adapted wizard framework class). This accessibility permits the wizard framework object to invoke page object methods as necessary to trigger various page operations (e.g. the display of a particular page) in response to events detected at the framework level (e.g. a navigational control button event).
The loss of data upon a user's premature cancellation from a wizard UI (described above) is characteristic of known wizard UIs implemented in an object oriented programming language using a standard UI class library following the framework-page paradigm. Data loss in this case is typically a consequence of the developer's failure to override the wizard framework object's default behaviour (i.e. to simply exit the wizard) upon the detection of a “cancel” button event. Even when this default behaviour is overridden, the developer usually only adds code to invoke various cleanup operations (e.g. memory de-allocation). As a result, the data loss problem is not alleviated by known techniques of developing wizard UIs using standard UI class libraries.
What is therefore needed is a wizard UI which permits the wizard to be cancelled and later resumed without loss of data. What is also needed is a system for displaying such a wizard UI. What is further needed is a method of developing such a wizard UI in an object oriented programming language using a standard UI class library following the framework-page paradigm.